扩展JSON编码规则(JER)

ITU-T在X.697 (JER)中标准化了ASN.1数据的JSON编码，但是我们相信客户很想支持使用这些还没有解决的标准方案。本文简要描述了JER的两个扩展，我们计划在我们的ASN.1编译器ASN1C中实现它们。我们计划在9月到10月的时间框架内实现第一个扩展(用于内容约束)，作为7.3 x补丁发行版中的一个未文档化特性。

内容约束的扩展

第一个扩展与带有内容约束的位字符串或八位字符串的编码有关。例如：

八字节字符串(包含某种类型)

简而言之，第一个扩展的目的是允许将包含的类型编码为JSON，就像它不是包含的类型时编码的一样，而不是将它编码为十六进制字符字符串。这个扩展的目的就是让JSON更易于阅读。这里有一个例子：

假设你的ASN.1是这样的： 我们的扩展会产生类似这样的东西： "my-bit-string" : { "value" : "7B20226F6E6522203A20226D6F6E6579222C202274776F22203A202273686F7722207D", "length" : 280 } 标准JER编码应该是这样的： "my-bit-string" : { "value+" : { "one" : "money", "two" : "show" } }

扩展未知类型的值

第二个扩展与未知类型的编码值有关，这些未知类型可以作为SEQUENCE/SET/CHOICE扩展元素或开放类型出现。将未知类型的值从BER或PER转换为标准JER是不可能的，因为它的类型是未知的，所以这个值被困在BER或PER中。因此，简而言之，我们第二个扩展的目的是支持将其余数据转换为JSON，同时保留不能正确转换的内容(如果需要的话)，并尽可能返回原始编码。这是通过将原始编码以十六进制形式嵌入JSON中实现的，并在必要时提供一些补充信息。

下面是一些使用我们的扩展生成的JSON示例。

处理未知的开放类型值:

"some-open-type-element" : {
        "encoding-rules+" : "BER",
        "encoded-data+" : "03020101"
      }

处理未知序列或集合扩展元素

"extensions+" : {
        "encoding-rules+" : "BER",
        "encoded-data+": [ "hex for extension X", "hex for extension Y" ]
    }

处理未知的选择扩展元素:

some-choice-field : {
      "extension+" : {
        "encoding-rules+" : "PER",
        "encoded-data+" : "04020301",
        "encoded-per-index+" : 5
     }
 }

这篇文章发表于2019年7月10日星期三11:22;